REMARKS 

The Examiner is thanked for his review of this application. Claims 1-22 
remain pending after entry of the present Response. 

Rejections under 35 U.S.C. § 103 

Claims 10 and 12-21 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over Finch et al. ("Finch") (U.S. Patent No. 5,805,796) and Ashe et al. ("Ashe") (U.S. 
Patent No. 6,307,574 Bl). These rejections are respectfully traversed. 

To establish a prima facie case of obviousness, there must be some suggestion or 
motivation, either in the references or in the knowledge generally available to one having 
ordinary skill in the art, to combine the references. Additionally, the references when 
combined must teach or suggest all the claim limitations. As discussed below, the Office 
has not established a prima facie case of obviousness because there is neither suggestion 
nor motivation, in either the references or in the knowledge of one having ordinary skill in 
the art at the time of the invention, to have combined the references in the manner 
proposed. Furthermore, the references when combined do not teach or suggest all of the 
claim limitations. 

Ashe teaches a method by which program code relating to GUI elements can be 
organized into a multi-level structure of classes. A class defining a structure and a function 
of the GUI element resides at one level within the multi-level structure of classes. A class 
defining an appearance of the GUI element resides at another level within the multi-level 
structure of classes. Only one instance of the class defining the structure and the function of 
the GUI element is required, regardless of the number of instances of the class defining the 
appearance of the GUI element. In this manner, Ashe teaches the implementation of 
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multiple appearance themes for a GUI element without having to repeat the structure and 
function class definitions for each theme. 

With regard to claim 10, the Office asserts that Ashe shows examining the class 
definition of a screen element of a GUI (column 3, lines 10-20 and column 6, lines 1-25) 
wherein examining is performed without execution of the class definition (column 5, lines 
5-14), and identifying an element if the class definition includes a method supporting the 
element (column 6, lines 5-10 and 34-55). Ashe (particularly column 3, lines 10-20 and 
column 6, lines 1-25) does not teach or suggest examining a class definition of a screen 
element of a GUI to detect an ability to process an input device's events . Ashe only teaches 
a multi-level class structure for separating the code associated with functionality and 
structure of the GUI element from the code associated with appearance of the GUI element. 
Thus, Ashe only teaches a method by which the class definitions of a GUI element are 
organized. Ashe does not mention or infer any examining. Furthermore, examining a class 
definition of a screen element of a GUI to detect an ability to process an input device's 
events is not pertinent to what Ashe is teaching. 

Further with respect to claim 10, the claim recites that said examining is performed 
without execution of said class definition. Ashe (particularly column 5, lines 5-14) does not 
teach or suggest that said examining is performed without execution of said class definition. 
As previously stated, Ashe does not teach or suggest said examining at all. Ashe, column 5, 
lines 5-14, actually teaches that "functionality associated with an object may also include a 
behavioral characteristic in which the object occupies different states in dependence upon 
user actions . For example, when a push button is actuated or a menu command is selected, 
it may go from a normal state to a highlighted state." Thus, it is clearly stated in Ashe that 
the behavioral characteristics (e.g., changing the appearance of the GUI element) is 
dependent on user action . Notwithstanding the fact that Ashe does not teach or suggest said 
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examining, the teachings in Ashe as cited by the Office (column 5, lines 5-14) actually 
teach away from the claimed invention. Specifically, claim 10 states that said examining is 
performed without execution of said class definition. According to Ashe, an object's 
functionality with regard to behavioral characteristics (e.g., object appearance) is dependent 
on user action (i.e.. user activation of the object) which directly contradicts the presently 
claimed invention, which states that said examining is performed without execution of said 
class definition. 

Further with respect to claim 10, the Office asserts that identifying an element if the 
class definition includes a method supporting the element is taught by Ashe, column 6, 
lines 5-10 and 34-55. First of all, the subject portion of the claim reads as follows: 
"automatically identifying said screen element as supporting input device input if said class 
definition includes a method supporting said input device's input." It is not clear that the 
Office's statement of "a method supporting the element" is equivalent to the claim language 
of "a method supporting said input device's input." Notwithstanding this ambiguity, Ashe 
(column 6, lines 5-10 and 34-55) still fails to teach or suggest this particular element of the 
claimed invention. Ashe (column 6, lines 5-10 and 34-55) teaches that each separate 
appearance of a control object has its own definition with its own associated program code. 
Ashe also teaches the use of core control classes to implement the basic functionality and 
overall appearance of the control objects. In the context of Ashe, there is no teaching that 
corresponds to examining the core control classes associated with the control object to 
identify the associated GUI element if the class definition includes a method supporting an 
input device's input. Thus, the teachings of Ashe (column 6, lines 5-10 and 34-55) are not 
relevant to the presently claimed invention. 

Further with respect to claim 10, the Office states the following: "Ashe et al. do not 
specifically state the element is supporting an input device, but does use class definitions to 
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determine support for an element, for analysis and control of the gui system." The 
applicants agree that Ashe does not specifically or inferentially state, teach, or suggest 
examining a class definition of a screen element of a GUI to detect an ability to process an 
input device's events . There are no teachings or suggestions in Ashe related to determining 
support for an element . Ashe simply teaches the use of class definitions organized in a 
hierarchical manner to provide for efficient multiple themed implementation of GUI 
elements such as a control objects or menus. "To determine support for an element" or "to 
detect an ability to process an input device's events" are both objectives that require specific 
actions to be accomplished. The mere fact that Ashe, or any other reference, uses class 
definitions to implement a screen element of a GUI does not imply that there is a 
determination or detection being made of the class's capabilities. Such a determination or 
detection involves specific and focused actions that are not taught or suggested by Ashe, 
but are claimed by the present invention. 

Further with respect to claim 10, the Office asserts that Finch determines that the 
element is supporting an input device (column 5, lines 60-68 and column 6, lines 1-20), in a 
system using class definitions for analysis and control of a GUI system (column 8, lines 29- 
45). Finch does not teach or suggest any part of claim 10. Furthermore, the cited portions of 
Finch as relied on by the Office do not appear to be pertinent to the presently claimed 
invention. Additionally, there is no suggestion or motivation in either Ashe or Finch to 
combine their respective teachings. It is respectfully submitted that the Office has not 
established a prima facie case of obviousness. 

With regard to claim 12, the Office refers to Ashe (column 5, lines 7-14) to assert 
that the examining is performed at runtime. As previously submitted, Ashe does not teach 
or suggest examining a class definition of a screen element of a GUI to detect an ability to 
process an input device's events . Furthermore, as previously submitted, Ashe (particularly 
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column 5, lines 5-14) does not teach or suggest that said examining is performed without 
execution of said class definition. 

With regard to claim 13, the Office refers to Ashe (column 5, lines 1-13) to assert 
that the element is marked if the class definition includes support for the input device. 
However, Ashe does not teach marking said screen element if said class definition includes 
a method supporting said input device's input, wherein said class definition has been 
examined, without execution, to detect an ability to process an input device's events. In 
contrast to the claimed invention, Ashe teaches changing the appearance of the screen 
element in response to user execution of the screen element. 

With regard to claim 14, the Office refers to Ashe (column 4, lines 55-68) as 
showing that the process was delegated to other code. Claim 14 requires that said 
examining step (in claim 10) includes determining if said screen element has delegated 
processing of said input device's input to other program code and identifying said screen 
element as supporting said input device if said processing is so delegated. As previously 
submitted, Ashe does not teach or suggest examining a class definition of a screen element 
of a GUI to detect an ability to process an input device's events , much less extending said 
examination to other program code to determine if said screen element has delegated 
processing of said input device's input. 

The Office states that claims 15-21 show the same features as claims 10 and 12-14 
and are rejected for the same reasons. Correspondingly, it is submitted that a prima facie 
case of obviousness against claims 15-21 has not been established in view of Ashe and 
Finch for at least the same reasons as previously identified with respect to claims 10 and 
12-14. 

Neither the teachings nor the nature of the problem solved in either Ashe or Finch, 
or the combination thereof, motivate or suggest to one of ordinary skill in the art at the time 
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of the invention to combine the reference teachings in a manner that would make the 
claimed invention obvious. Furthermore, neither Ashe nor Finch, nor the combination 
thereof, teach all of the features of claims 10 and 12-21. Thus, a prima facie case of 
obviousness has not been established. For at least these reasons, the Applicants respectfully 
request that the rejections of independent claims 10, 15, 18, and 21 be withdrawn. For at 
least the same reasons, the Applicants respectfully submit that dependent claims 12-14, 16- 
17, and 19-20 are patentable over the cited art of record. 

I Accordingly, a notice of allowance is respectfully requested. Alternatively, the 

Applicants submit that the claims, in view of the art of record, are in condition for Appeal. 
If the Examiner has any questions concerning the present amendment, the Examiner is 
kindly requested to contact the undersigned at (408) 749-6900 x6903. If any additional fee 
other than the enclosed fees are due in connection with filing this amendment, the 
Commissioner is authorized to charge to such fees Deposit Account No. 50-0805 (Order 
No. SUNMP068). A duplicate copy of the transmittal is enclosed for this purpose. 



Respectfully submitted, 
MARTINE & PENILLA, LLP 




Alberts. Penilla, Esq. 
Reg. No. 39,487 



MARTINE & PENILLA, LLP 
710 Lakeway Drive, Suite 170 
Sunnyvale, CA 94085 
Telephone: (408) 749-6900 
Customer Number 32291 
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